如何将dvd转换为自适应流媒体:2 / 4

欢迎来到我们案例研究的第二部分, 我们把三张训练dvd转换成多个H.264文件用于自适应流式传输(如果你错过了第一部分，请点击这里). In this section, 我将详细说明我们如何在自适应流媒体产品中提供文件的数量及其配置, 以及我们如何测试多文件服务. As a reminder, 完成项目取决于满足客户的质量相关目标, 我将在这部分的最后讨论.

我写过很多关于自适应流的文章，最全面的是 自适应流在现场 for Streaming Media Magazine. In that article, 我问了一些制片人，比如特纳广播公司, NBC (through Microsoft), Harvard University, 以及德国之声有关流计数的具体问题, data rate, resolution, and encoding methods. 如果你不熟悉自适应流媒体, 我会阅读那篇文章，以便更好地了解与压缩相关的决策, 回来看看他们是如何应用于这个项目的.

Stream Count and Data Rate

我们的第一个决定是流的数量, 这篇文章的受访者中有3到8人. 很大程度上影响了我的决定, 我们考虑了目标观众, SunCam设想他们会如何观看视频, 以及源视频的分辨率.

Specifically, 因为观众都是专业的工程师, 客户觉得连接带宽会非常高. In addition, 因为视频很长，而且是为了训练, 客户认为质量必须是好的, 因此，降低到超低的数据速率既没有必要也不建议.

Finally, 因为视频是4:3的SD源, 最大分辨率为640x480, 所以我们可以只制作三到四个流媒体，仍然覆盖最相关的观众. 最初，我们决定尝试四种速度为400kbps, 700kbps, 1的流.0 Mbps and 1.5 Mbps，但在我们第一次向客户演示后，最终下降了最低质量的流. More on that experience below.

Resolution

下一个问题是编码分辨率. 同样，由于视频的性质，SunCam认为观看分辨率必须为640x480. 我们可以通过两种方式实现:在那个分辨率下编码，或者在较小的分辨率下编码，然后缩放以适应显示窗口, 许多自适应百家乐软件app最新版下载使用的是哪种技术.

To a degree, 我们在这里的决定是由位于视频最开始的一些介绍性镜头驱动的，您可以在图2中看到. Basically, 当以480x360分辨率编码，然后放大到640x480(如图所示)时，它看起来很糟糕。, 但是当编码为640x480时，数据速率是相同的(右图). 由于客户的目标是像netflix一样的体验，我们不想在介绍时搞砸它, 所以我们采用了原生分辨率. Interestingly, 这段视频还说明了我们在哪里对DVD片段进行了去隔行处理以及使用了哪种算法.

请注意，如果我们的目标是低得多的数据速率，或者如果内容不包含具有这种精细细节的部分，那么这个决定可能会有所不同. 我们最初的计划是在640x480和480x360下测试400kbps的流, both displayed at 640x480, 并选择最高质量的选项. 如果你想在这两种方法中做出选择, 您应该运行一些并行测试，看看哪种测试最适合您的内容.

Other Encoding Parameters

当编码自适应流, 有几点需要记住, 所有这些都在上述文章中得到了充分的充实. First, 我建议使用恒定比特率编码, 由于可变比特率编码可以人为地触发流的变化.

Second, 当为自适应流生成多个文件时, 你需要一个一致的关键帧间隔，在场景变化时没有关键帧. 由于Adobe的动态流只能在关键帧切换流, 关键帧间隔应该比平时短. 通常我建议关键帧间隔为10秒, 在这些视频中，我用了三秒钟.

请注意，当生产其他技术, 比如苹果的HTTP直播, Microsoft's Smooth Streaming, 以及Adobe基于rtmp的自适应流媒体, other considerations, like chunk size, also matter. 我在前面提到的文章中提到了一些，但在我的书中提供了更多的信息， 视频压缩Adobe Flash，苹果设备和HTML5.

你必须为自适应流专门编码的另一个领域与音频参数有关, 对于所有流，哪个应该是相同的. 否则，您可能会在场景变化时听到爆裂声或其他伪影. 由于视频中的大多数音频都是单声道语音，所以我在所有文件中都以64kbps的单声道编码.

Testing the Adaptive Streams

当我在编码方面瞎折腾的时候, Stefan Richter, 是谁把我带进这个项目的, 同时开发玩家吗. 当我们最终确定关于流计数和配置的想法时, 我们想向客户端展示流交换是什么样子的. In Stefan's final player, however, 不存在强制流切换的机制, 因为这些都是由玩家和服务器自动处理的.

Fortunately, Stefan在Adobe的开源媒体框架(OSMF)中找到了一个播放器，它提供了强制流切换的控件, 他可以修改它来播放我们的文件. 如图4所示，使用了Adobe提供的视频. 如果你看一下玩家控制栏, you'll see the letter Q, 你点击它可以显示Q-和Q+控件，点击它可以在比特流之间切换. As you can see, 播放器显示文件的比特率，然后在控制之间播放(即408 kbps).

我们大多数人都看过以一种或另一种自适应流媒体形式分发的视频, 但是很难判断流何时被切换, 如果没有复杂的网络设备，很难强迫流切换. 虽然OSMF播放器是公认的粗糙, 流切换本身是绝对完美的, with no stops, skips, or audio artifacts. I was impressed, 客户端也是如此——通过流切换, 但不是一些流的质量. 正如我在第一期中提到的, 如果我们不能达到或接近Netflix的质量，客户就不想继续前进. 我制作的一些流没有达到这个标准.

Here's why. 我们编码的大多数视频都是穿插着幻灯片的简单的说话头像, some figures, 还有观众的b-roll——很容易压缩内容. On the other hand, 视频的介绍制作得相当高, with some very artsy pans, zooms, transitions, 以及难以压缩的素材，如图2所示.

我最初的测试视频从中间截取了一部分, 视频在所有数据速率下看起来都很好. 但后来我意识到，这并不能代表整体质量, 所以我重新编码了一个片段，其中包含了一些难以编码的介绍镜头, 和易于编码的说话头, 这就是我们在OMSF播放器中向客户展示的内容. Overall, the quality was good, 除了在剪辑开始时快速缩小, 在所有数据速率下看起来都很糟糕(图5), 以及下面讨论的一些非常详细的镜头. 就在视频开始的时候，它就像一个疼痛的拇指一样突出，给人留下了不好的印象.

Bill, the client, was resolute, matter of factly stating, “即使是1500美元，样本也不太接近Netflix的体验. 如果这是我们能从Flash中得到的最好的东西，那么你就不应该再继续下去了. 我可能需要重新考虑这个项目，并找到一个Silverlight主机来取代AWS."

To explain the last comment, 因为Netflix使用Silverlight, 比尔认为问题出在技术上, 不是编码技术或素材. 这时，我打电话给比尔，我们讨论了三点.

首先，无论他是使用Silverlight还是Flash, H.264可能是编解码器，改变平台根本不会影响质量. Second, 项目开始时的素材根本不可能以高质量压缩, 不考虑平台和技术. Third, 原始编码或多或少是草稿编码，以测试自适应流的操作, 我觉得我可以做得更好.

我们同意从测试剪辑中删除第一个快速缩放, 在他再次查看之前，我会将结果测试剪辑重新编码为建议的最终参数. 这也是我们决定放弃400kbps的片段，并使用剩下的三个700kbps和1.0 and 1.5 Mbps.

总的来说，Stefan完成了他的工作——自适应流媒体看起来很棒. 但如果我不能提高质量，这个项目就会付之东流. 下周请收看我的演讲.

Jan Ozer的文章首先出现在在线视频上.net